Hey stephenrjohnson, could you take a look at the code?

I'll get to this on the weekend, sorry about the delay.

I'm interested in having this merged as well please @stephenrjohnson

Hey @stephenrjohnson
possible for you to take a look at this?

epel offers python-gunicorn.. ? why compile it?

i think there should be an option to use a local package - i try to avoid compiling on production machines where i can...

Well, unicorn isn't the same as gunicorn. In general I noticed that the rpms are most of the time outdated so I prefer gems. Also unicorn isn't available via base/epel/extras repos on CentOS7

bastelfreak - i just actually just realised my error there. yep..
Sorry bout that..

Is it possible to have the option of using a package instead though?
ill often build my own packages and distribute them for my systems

So an option to swtich between the gem or an rpm and the option to specifiy the name of the rpm? Can I assume that the rpm is available via any configured repository? would this suit your needs?

I'm holding off merging this until you have made the changes, outlined above.

bastelfreak, exactly 👍

in my situation id simply like to offer a rpm package name, which would avoid installing and building using gcc - etc.

Soo setting the package_name

it would also be important to set

installpath - https://github.com/stephenrjohnson/puppetmodule/pull/74/files#diff-85eb9f3c6e80aebeebc8c583f5afd80bR5

and i noticed you arent using the puppet_passenger_port -> https://github.com/stephenrjohnson/puppetmodule/pull/74/files#diff-d52434b9535ec86f061db077733da1fbR23

there are other modules out there which manage repository management.
Lets assume that the rpm should just be available to the system :)

Can I assume that the binary is always available in your $PATH? Your do you want to specify the complete path to the binary?

I will try to add the changes later this week. are you able to write some unit/rspec tests?

hey @stephenrjohnson could you please take a look at this? implemented the mentioned stuff from @arenstar

let me know if I should rebase it into one commit

tested this yesterday on several nodes together with @gavinrogers and we fixed two bugs. currently it is running fine on multiple production systems

The last think we need is some tests as this is a massive change. Have a look in spec/acceptance/ and we don't have any spec tests to test both branches of the webserver tree or even any for the unicorn class.

anybody with a bit of experience in writing tests around that could assist me? Maybe @gavinrogers ?

@stephenrjohnson i've started working on spec tests etc. i was curious about the acceptance tests, i noticed that one of the targets is centos7, but i haven't yet found a way to install passenger on centos7, where is the package coming from? i've got it working fine on that platform using the unicorn class, let me get the tests done

You're writing the tests? Awesome! thanks!

@gavinrogers If you look at the spec_helper_acceptance

if osfamily == 'RedHat'
on host, puppet('module', 'install', 'stahnma-epel'), { :acceptable_exit_codes => [0,1] }
on host, puppet('apply', '-e', '"class {epel:}"'), { :acceptable_exit_codes => [0] }
#passenger repo
shell("rpm -iv http://yum.theforeman.org/releases/latest/el#{osrelease}/x86_64/foreman-release.rpm")
end

Extremely interested in this option. The rest of our stack runs on Nginx & Unicorn/Gunicorn so this would sit within that perfectly.

Obviously the progress on this change has been slow lately. Is there anything I can do to assist in merging it in? Happy to assist with puppet code, testing etc

please please please write tests. I've no clue about that, would be awesome if you could contribute it.

Is that the only change necessary? I'd like to see the vhost for nginx setup using jfryman/nginx. Can do that too if you'd like?

I can take a look again and try to create a vhost config via jfryman/nginx. Do you know a bit about selinux and can maybe improve the current settings?

I've merged all the upstream code and fixed all existing tests (other than ones not passing upstream). Whilst writing unit tests for unicorn though I noticed that none of the parameters for puppet::unicorn have default values at this point. I might have to make some more significant modifications to get it working in a sane manner.

looks way better now, travis shows only three issues, all not based on this code.

The issues are caused by your merges not being clean this really needs rebasing on matser.

rebase is on its way!

@stephenrjohnson would it be okay for you if I squash this into one commit before rebasing?

Not the best but sure it's fine.

Did a huge squash and then rebased against your master

Why is this still breaking the tests that work before the merge.

hey @stephenrjohnson, could you have a look again? Did a new rebase and fixed the two travis issues (trailing whitespace and missing variable scope). Can you tell me why travis is failling?